Repository navigation
fix(native-api): return the parser's reason for a rejected managed entry - #140
Merged
Merged
Conversation
5 of 9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
POST /api/v1/nodeswith a link that honk cannot parse returned the generic422message "The main source cannot hold this node name and share link" (crates/honk-core/src/native_api/config/coordinator.rs:384-389,origin/feat/native-api0e9f2a3):append_node_sourcecollapsed every failure into the unitSourceEditError(crates/honk-config/src/parser/source_edit.rs:36-38, 400-445) and discarded the parser's diagnostic, so an XHTTPextrasuch as{"xPaddingBytes":"0-10"}gave no reason, although the contract asks for a sanitized reason inerror.message. The three XHTTP range checks also shared one message, "XHTTP range exceeds supported bounds" (crates/honk-config/src/node/xhttp.rs:571-579). Separately, a client editing a node through a source write cannot tell a skipped entry from an accepted one: the node parser downgrades a link failure to a warning (crates/honk-config/src/parser/entries.rs:134-147), so the reload succeeds and the node disappears, and nothing stated which warnings an accepted link can produce.How I fixed it
SourceEditErrornow carries an optional staticreason, whichmanaged_entryfills from the parse error, the last warning of a skipped entry, or full admission; node and provider creation return it aserror.messageand keep the generic message otherwise, with unchangeddetailsand no submitted value. Each XHTTP range names its Xray key and bounds.Node::parse_share_linkdebug-asserts that a link's warnings uselegacy-*codes, which both of today's emitters already do, anddoc/*/reference/nodes.mdstates that rule so a client can validate onenode {}declaration insyntaxmode and treat any other warning as a dropped entry; doona's node dialog (Zakkaus/doona#542) relies on it.doc/*/reference/api.mdand.agents/rules/configuration.mdare updated.Verified
cargo test -p honk-config: 565 passed, includingmanaged_node_rejection_keeps_the_static_parser_reason, which fails with thexhttp.rschange reverted (leftXHTTP range exceeds supported bounds).cargo test -p honk-core --features native-api --lib native_api::: 398 passed, includingrejected_node_links_report_the_static_parser_reason, which fails with thecoordinator.rschange reverted (left the generic message).cargo clippy --all --all-targets --features honk-core/native-ui -- -D warnings,cargo clippy --workspace --all-targets --no-default-features -- -D warningsandcargo fmt --all -- --checkare clean, and each commit passescargo check -p honk-config -p honk-core --features honk-core/native-api. Against a local honk-core with mock eBPF and doona served fromdist/,POST /nodeswith{"scMaxEachPostBytes":0,"headers":{"X-K":"private-value"}}returned422"XHTTP scMaxEachPostBytes must stay within 1-16777216" without the header value and wrote nothing, andsyntaxvalidation of that declaration returned the same message as aninvalid-config-valuewarning. Not run:just test-ci, the full honk-core and workspace suites,just test-netns; honk-core test builds were OOM-killed at default parallelism here and ran with-j4and debug info off. The provider-side reason has no test, because I found no input that passes the earlier URL and user-agent checks and still fails the parser.Follow-up, not changed here: VMess JSON XHTTP still collapses every option failure into "unsupported or invalid VMess XHTTP option" (
crates/honk-config/src/share_link/xhttp.rs:151, 168-171, which discard the mode-conflict andfrom_xray_extramessages), so a VMess link gets no field-level reason; this predates the branch. Issues are disabled on this repository, so it is recorded here.AI disclosure: the code, tests, docs and this description were written by an LLM agent (omp, Claude), with separate adversarial and code-quality review passes whose findings are addressed here. A maintainer has not yet reviewed the result.
just fmt,just lintandjust test-cipass.doc/en/anddoc/zh/if I changed documented behaviour.CONTRIBUTING.mdandAGENTS.md, and Verified shows what I ran, not guesses.